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In response to the Final Official Action mailed January 15, 2004, applicant submits the 
following remarks. 

Reconsideration and allowance of the above-referenced application are respectfully 
requested. Claims 1-13 are unchanged and remain pending in the application. 

At the outset, Applicant traverses the Final Official Action as incomplete because it fails 
to answer all of the material traversed as required see MPEP 707.07(f). In particular, the Official 
Action: (1) fails to acknowledge or address the evidence submitted as Exhibits A and B in the 
Response filed October 14, 2003 (hereinafter "Prior Response"); (2) fails to explain why the 
claim interpretation of "determining an application state for a prescribed network application" 
the Final Official Action could be considered "reasonable" despite its inconsistency with the 
specification; and (3) fails to address (let alone rebut) the numerous examples provided by 
Applicant that demonstrates how the layer 2/ layer 3 address aging operations disclosed in the 
applied references cannot be considered equivalent to the claimed "determining application 
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state". 

Hence, Applicant requests the Finality of the Office Action be withdrawn, and that a 
corrected Office Action be issued that addresses the above-noted deficiencies. 

Claims 1 and 10 stand rejected under 35 USC § 102(e) in view of U.S. Patent No. 
6,094,435 to Hoffman. This rejection is respectfully traversed. The comments submitted in the 
Prior Response are incorporated in their entirety herein by reference. The following address the 
comments in the Final Office Action. 

The Final Official Action asserts on page 4 (Response to Arguments) a supposed rebuttal 
to the assertion in the Prior Response that Hoffman neither discloses nor suggests the claimed 
determining an application state for a prescribed network application from a received layer 2 data 
packet: 

In response, Hoffman has clearly shown layer 2 information stored in a memory. The 
entry contains information relating to source and destination aging [sic]. Destination 
aging in the network element indicates which layer 2 and layer 3 entries are active. 
Determining which layer 2 and layer 3 entries are active is equivalent to [sic] determining 
an application state for a prescribed network application. 

(Pages 4-5 of Final Office Action, Paragraph 10, lines 3-8). 

This assertion is: (1) unfounded; (2) inconsistent with the explicit teachings of the 
reference and notoriously well recognized teachings in the art; and (3) another example of a 
tortured and unreasonable interpretation of Hoffman which is necessitated by the fact that 
Hoffman fails to disclose each and every element of the claim . 

In particular, the Final Office Action makes the ill-founded and nonsensical assertion that 
determining which layer 2 and layer 3 entries are active is "equivalent to" determining an 
application state. However, the Final Office Action fails to provide any evidence to substantiate 
this argument that determining which layer 2 and layer 3 entries are active is equivalent to 
determining an application state. 

Moreover, the assertion of equivalency is inconsistent with the explicit teachings of the 
applied Hoffman reference. In particular, Hoffman explicitly teaches that, unlike layer 4, the 
OSI layers 1 through 3 do not provide application services: 



Response After Final filed March 15, 2004 
ApplnNo. 09/519,848 
Page 2 



A key difference between the transport layer [i.e., layer 4] and the lower layers [1 through 
3] is that an application on a source end station can carry out a conversation with a 
similar application on a destination end station anywhere in the network; whereas the 
lower layers carry on conversations with end stations which are its inunediate [sic, 
immediate] neighbors in the network. Layer 4 protocols also support reliable connection 
oriented services, an example Layer 4 protocol providing such services is the Transport 
Control Protocol (TCP). 

(Col. 2, lines 31-38). 

The distinction is significant because unlike layer 2 and layer 3, layer 4 (transport) layer 
provides a port address used to uniquely identify a given network application: "Layer 4, the 
transport layer, provides application programs such as an electronic mail program with a 'port 
address' which the application can use to interface with the data link layer." (Col. 2, lines 27-3 1). 
Note, however, that Hoffman only discloses that layer 4 is capable of providing support for a 
given network application by assigning a port address to interface with the data link layer; 
Hoffman does not provide any description of application state relative to layer 4. 

This description of the OSI model in Hoffman is consistent with Exhibit B that was 
submitted in the Prior Response, which describes in further detail each of the OSI layers, namely 
the Physical Layer (layer 1), Data Link Layer (layer 2), Network Layer (layer 3), Transport Layer 
(layer 4), Session Layer (layer 5), Presentation Layer (layer 6), and Application Layer (layer 7). 
For example, both Hoffman and Exhibit B acknowledge that reliable connection oriented 
services such as TCP are examples of layer 4 protocols. 

Hence, both Hoffman and Exhibit B recognize that layer 2 and layer 3 protocol 
operations have no relation to application layer protocols, especially since Exhibit B 
demonstrates that network applications such as HTTP, SNMP, FTP, Telnet (cited in page 5, lines 
1 1-13 of the specification as examples of network applications) are examples of Layer 7 
Application Layer protocols. 

In addition, the Final Office Action blatantly disregards the explicit teachings of the 
reference at column 16, lines 43-53, as evidenced by the lack of any acknowledgment of Exhibit 
A, which is the same standard cited bv the reference : Exhibit A (the IEEE 802. ID Specification 
(1998)) specifies on page 45 that entries " shall be automatically re moved after a specified time, 
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the Ageing [sic] Time, has elapsed since the entry was created or last updated." Further , Table 
7-4 of the IEEE 802. ID Specification specifies a range of applicable aging parameter values with 
a recommended default value . 

Hence, Hoffman merely discloses that aging is based on whether a matching address 
(layer 2 or layer 3) is detected before expiration of the aging interval, in order to remove inactive 
address entries (defined as no activity within the prescribed aging interval) from the forwarding 
memory 40 to prevent overflow thereof Hence, Hoffman describes no more than the 
Background Art described on pages 1-2 of the specification. 

Finally, Hoffman makes no reference whatsoever to any state, let alone detection of an 
application state, as claimed. 

Hence, the argument that "determining which layer 2 and layer 3 entries are active is 
equivalent to determining an application state for a prescribed network application" is without 
foundation. 

As demonstrated above, the Final Official Action does in fact interpret the claims in a 
manner inconsistent with the specification, and hence unreasonably: the specification describes 
HTTP, SNMP, FTP, and Telnet as examples of network applications on page 5, lines 11-13. 
Rather than addressing the examples cited in the specification, the Final Official Action asserts 
the unfounded and nonsensical assertion that "determining which layer 2 and layer 3 entries are 
active is equivalent to determining an application state for a prescribed network application". 
This assertion is per se unreasonable, and demonstrates that the claims are being unreasonably 
interpreted to equate the claimed application state for a prescribed network application with 
determining link state for layer 2 or layer 3 entries. 

Further, the specification at page 1, line 24 to page 2, line 12 describes problems 
associated with conventional layer 2 aging processes using a hit bit for deleting aged address 
entries from an address table as incapable of detecting higher-protocol communications between 
two network applications . 

Further, the specification describes at page 5, lines 19-22 how different aging parameters 
can be established for an HTTP packet, an SNMP packet, and a video/voice packet, respectively. 

Further, the Final Office Action mischaracterizes applicant's arguments on page 5, lines 
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3-12 (part of paragraph 10) as arguing features not claimed; however, the response explicitly 
specified on page 7 that these features are examples from the specification to support the 
assertion that the broadest reasonable interpretation of "determining an application state for a 
prescribed network application" cannot be inconsistent with these examples. 

The Final Office Action fails to cite a single example to rebut the numerous substantiated 
examples cited by Applicant to demonstrate that the Final Office Action applies an unreasonable 
interpretation of both the claims and the applied reference. 

Hence, the rejection is legally inadequate because the Official Action fails to demonstrate 
how Hoffman discloses each and every element of the claim. Hoffman fails to disclose or 
suggest " determining an application state for a prescribed network application from a received 
layer 2 data packet" (claim 1) or " determining an application state for a detected one of a 
plurality of prescribed network applications from a received layer 2 data packet" (claim 10). 
Further, independent claims 1 and 10 specify "selectively deleting an address entry ... based on 
the determined application state ." Hence, the rejection should be withdrawn because it fails to 
demonstrate that Hoffman discloses each and every element of the claim . See MPEP 2131. 
"The identical invention must be shown in as complete detail as is contained in the ... claim." 
Richardson v. Suzuki Motor Co. . 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
"Anticipation cannot be predicated on teachings in the reference which are vague or based on 
conjecture." Studiengesellschaft Kohle mbH v. Dart Industries. Inc. , 549 F. Supp. 716, 216 
USPQ 381 (D. Del. 1982), affd. . 726 F.2d 724, 220 USPQ 841 (Fed. Cir. 1984). 

For these and other reasons, the §102 rejection of claims 1 and 10 should be withdrawn. 
Claim 2 stands rejected under 35 USC § 103(a) in view of Hoffman and U.S. Patent No. 
5,128,926 to Perlman. This rejection is respectfully traversed. The comments from the Prior 
Response are incorporated in their entirety herein by reference. 

As demonstrated above, the Final Official Action takes the unreasonable position at page 
5, paragraph 11, lines 2-3 that "Hoffman teaches determining application state": no such 
disclosure or suggestion is present in Hoffman, especially since Hoffman makes no reference 
whatsoever to "state", let alone the claimed "application state". 

Further, the Final Office Action makes the ill-founded and legally improper argument 
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that: 

In order for Perlman to determine the operative or inoperative status of the links, it would 
be inherent [sic] for Perlman to have a reference to use to determine the status; this 
reference in each node is a template. 

(Page 5, paragraph 11, lines 8-10 of Final Office Action). 

This assertion improperly relies on inherency: Inherency is not applicable in a rejection 
under §103. In re Newell 13 USPQ2d 1248, 1250 (Fed. Cir. 1989). 

Further, the assertion of the Final Office Action is inconsistent with the explicit teachings 

of Perlman, which describes that link state information is managed using Link State Packets: 

In popular routing algorithms such as that described in "The New Routing Algorithm for 
the ARPANET" by McQuillan, Richer, and Rosen, IEEE Transactions on 
Communications, May, 1980, each node (e.g., router) determines which links are 
connected to it, the state of those links, and the identity of the node on the other end of 
each link. To initialize the network, each router places this information in a special packet 
known as a Link State Packet (LSP), and transmits this LSP to all of the other routers in 
the network. Later, when changes in the network occur (e.g., a link fails), one or more 
routers may generate new LSPs which supersede previously generated LSPs. 

(Col. 1, lines 31-43). 

Note that the Abstract of Perlman also specifies that Link State Packets are used to 
indicate the states of links. 

Moreover, the rejection fails to establish a prima facie case of obviousness because the 
rejection fails to show how Perlman teaches the claimed feature of claim 2: storing within a 
network switch port a plurality of templates configured for identifying the application state from 
respective available application states of the prescribed network application. The rejection 
merely cites Perlman at col 1, lines 1-28 regarding the description of link status, and does not 
address the claimed templates. 

Moreover, neither Hoffman nor Perlman, singly or in combination, disclose or suggest 
anv templates whatsoever , let alone any suggestion of storing within the network switch port the 



Response After Final filed March 15, 2004 
ApplnNo. 09/519,848 
Page 6 




claimed plurality of templates. 

For these and other reasons, the §103 rejection of claim 2 should be withdrawn. 

Claims 8-9 and 1 1 stand rejected under § 103(a) in view of Hoffman and U.S. Patent No. 
6,104,696 to Kadambi. This rejection is respectfully traversed. The comments from the Prior 
Response are incorporated in their entirety herein by reference. 

The Final Official Action again provides a tortured interpretation of the reference: 

Kadambi is clearly teaching an aging timer and the aging timer is specific to the 
application described [sic]. Kadambi clearly teaches that the aging process is only 
performed on entries where the port referred to belongs to the particular module which is 
performing the aging process (column 23, lines 20-24). 

This argument is nonsensical: Kadambi does teach that the aging process is performed 
only on entries that belong to the module having received the data packet, but this has no relation 
to the assertion that "the aging timer is specific to the application described". Rather, the aging 
timer is specific to the port having received the data packet . 

As described at column 22, lines 31-36 and 43-47 of Kadambi et al.: 

When ARL/L3 tables are updated to include a new source address, a "hit bit" is set within 
the table of the "owner" or obtaining module to indicate that the address has been 
accessed. ... The entry in the ARL/L3 tables includes an identification of the port which 
initially received the packet and learned the address. Therefore, if EPIC 20a contains the 
port which initially received the packet and therefore which initially learned the address, 
EPIC 20a becomes the "owner" of the address. Only EPIC 20a, therefore, can delete this 
address from the table. 

Further, column 22, lines 64-65 specify that "an age timer is provided within each EPIC 
module 20 and GPIC module 30". Hence, col. 22, line 63 to col. 23, line 27 are directed to an 
aging timer used by an aging process to delete aged entries that are stored in the owner of the 
address. Hence, the age timers of Kadambi are port-specific aging timers based on the port 
having received the packet carrying the learned address. 

Claims 8-9 and 1 1 , however, specify initiating counting of an application-specific aging 
timer. Neither Hoffman or Kadambi, singly or in combination, disclose nor suggest an 
application-specific aging timer configured for counting the application-specific aging interval 
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for a prescribed network application, as claimed. For these and other reasons, claims 8-9 and 1 1 
are patentable over Hoffman and Kadambi. Hence, this §103 rejection should be withdrawn. 

The indication of allowable subject matter in claims 3-7 and 12-13 is acknowledged and 
appreciated. It is believed these claims are allowable in view of the foregoing. 

In view of the above, it is believed this application is and condition for allowance, and 
such a Notice is respectfully solicited. 



Response After Final filed March 15, 2004 
Appln No. 09/519,848 
Page 8 



To the extent necessary, Applicant petitions for an extension of time under 37 C.F.R. 
1.136. Please charge any shortage in fees due in connection with the filing of this paper, 
including any missing or insufficient fees under 37 C.F.R. 1.17(a), to Deposit Account No. 
50-0687, under Order No. 95-307, and please credit any excess fees to such deposit account. 



Customer No. 20736 
Date: March 15, 2004 
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Respectfully submitted, 




Leon R. Turkevich 
Registration No. 34,035 



